Blind SQLi

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection

Blind SQL injection occurs when an application is vulnerable to SQL injection, but its HTTP responses do not contain the results of the relevant SQL query or the details of any database errors.

Many techniques such as UNION attacks are not effective with blind SQL injection vulnerabilities. This is because they rely on being able to see the results of the injected query within the application's responses. It is still possible to exploit blind SQL injection to access unauthorized data, but different techniques must be used.

DVWA - Example 1

The vuln in this code is found in the way the input from the user (_GET['id]) is directly embedded into an SQL query string without sanitization or parameterization.

• User input $id is directly interpolated into the SQL query.
• This query is executed by the application in $result
• There's no filtering or escaping to prevent malicious SQL from being injected

Note that errors are suppressed using @ and or die has been removed — so error messages don't reveal clues, making it blind SQLi (i.e., no output from the database, but we can infer behavior through the app's responses). The different output depending on the SQL query gives us a true/false channel to perform boolean based blind SQL.

This will return User ID Exists

id=1' AND 1=1-- -

This will return Missing

id=1' AND 1=2-- -

We can guess the number of rows in the users table using the same boolean SQL vuln.

id=1' AND (SELECT COUNT(*) FROM users) = 1-- -

Running UNION SELECT gets us a sleep delay

?id=1' UNION SELECT null, SLEEP(5)-- -

DVWA - Example2

This time, the input is passed through the mysql_real_escape_string(). This function escapes quotes and special characters.

However, the input isn't quoted in the SQL query. It's a numeric content and not a string. So if the attacker supplies a payload like 1 AND sleep(5) then it'll be inserted as is. Note the blind element here also.

We can see the response hanging here for 5 seconds.

1+AND+SLEEP(5)

We can also check the number of users in the database.

1+OR+(SELECT+1+FROM+users+LIMIT+3,1)--+-

BurpSuite - Blind SQLi with Out-Of-Band Interaction

Contains a blind SQLi vuln, the application uses a tracking cookie for analytics and performs a query containing the value of the submitted cookie. The SQL query is executed asynchronously and has no effect on the application's response. However, you can trigger out-of-bound interactions with an external domain. We want to exploit SQLi and cause a DNS lookup.

Grabbing the home (root) web directory, we'll look at this in the repeater

We can cause the database to do a DNS lookup to an external domain (target) via the burp collaborator client, this'll generate a unique subdomain that we can use in the attack, then poll the collaborator server to confirm a DNS lookup occurred. This is our unique client we've generated:

Payloads vary by database, we can just test each payload for this.

We'll add URL-encoded payloads to the TrackingId cookie that is suspected as having the out-of-band exploit present.

This gives us our response.

Now, knowing we have an OracleDB and we want to obtain the administrator's password, we can modify the query and hopefully exfiltrate the information to the Burp collaborator. We'll add the following to the payload:

SELECT password from users where username='administrator'

Polling the DNS of the target (as shown in the repeater) gives us DNS lookup responses that include the administrator password. We can now use this to log in.